This way, the strobealign sources are more self-contained and it should not
be necessary to have internet access at build time.

See https://github.com/alugowski/poolSTL

Sorting the randstrobes is currently a bottleneck in index generation as it
does not run in parallel. This is an attempt to parallelize it.

poolstl’s sort uses regular std::sort under the hood.
We currently use pdqsort_branchless, which is about twice as fast as
std::sort, so parallel sorting breaks even with pdqsort_branchless at about
2-3 threads. It gets faster with more threads, but not as much as one would
perhaps expect. Here are the sorting runtimes for CHM13:

- 31 s with pdqsort_branchless
- 59 s with std::sort
- 34 s with parallel sort, 2 threads
- 24 s with parallel sort, 4 threads
- 23 s with parallel sort, 8 threads

Another issue is that sorting is no longer in place, so memory usage goes
up by a couple of gigabytes, which is another reason for me not to make this
change.

This version indeed gives us a very nice speed improvement without using
extra memory:

Sorting-only runtimes:
* 1 thread: 32.8 s
* 2 threads: 20.3 s
* 4 threads: 15.7 s
* 8 threads: 14.8 s

Overall indexing runtimes (before/after):
* 1 thread: 151 s → 153 s
* 2 threads: 100 s → 88 s
* 4 threads: 73 s → 57 s
* 8 threads: 63 s → 47 s

... by sorting them also by position. This way, it does not matter in which
way the randstrobes vector is partitioned during sort. Otherwise, the order
would depend on the number of threads used to create the index, making
mapping results not reproducible across runs that do not use the same no. of
threads.

Note: There is still a tiny chance for collisions/nondeterminism because we
ignore RefRandstrobe::m_packed.

For efficiency, this uses a branchless comparison function inspired by
@alugowski’s comment in PR ksahlin#386.

Runtimes for sorting with one thread

32 s - only by hash
45 s - by hash and position using std::tie
42 s - by hash and position using branchless_compare from the PR
35 s - by hash and position using __uint128_t (this commit)

Runtimes for sorting (four cores with hyperthreading)

threads | sorting time | index creation time
-|-|-
1 | 35 s | 154 s
2 | 25 s | 95 s
4 | 16 s | 60 s
8 | 15 s | 48 s

Closes ksahlin#395

Right now, strobealign only supports up to 2²⁴ sequences. If the user
tries more, it would silently accept it, but later crash.

This was triggered when trying to map to the Greengenes database

https://ftp.microbio.me/greengenes_release/2022.10/
https://ftp.microbio.me/greengenes_release/2022.10/2022.10.seqs.fna.gz

Even a single read like the one below trigger a crash

```
@M05314:127:000000000-BWLLJ:1:1101:15267:1654 2:N:0:1
CCTGTTCGCTCCCCACGCTTTCGTCCCTCAGCGTCAATATTGTGCCAGAATGCTGCCTTCGCCATTGGTGTTCCTCCTGATATCTACGCATGTCACCGCTACACCAGGAATTCCACATTCCTCTCACATATTCTATTTTATCAGTTTTGAT
+
AAA1AF@1>AAAGG1A0EAFGGEHAAEGFCG1AAEE/F2FG2F2FF1CA0FBDED1BGFGFFE?AF1BFFCFHDGFFHB1FFGFGEEFE/?/BF2F@/EGEEB00/0//0BFG1>B1BGFEFHHGGFFD12BGH2FDFFFGG22GDD>@/F
```

This is 3-state variable: SAM/PAF/Abundance

RFCT aemb

Co-authored-by: Marcel Martin <[email protected]>